fix(vue-query): widen 'SkipToken' to 'symbol' so 'queryFn' type-checks as a 'computed' or inside a whole-options getter - #11427

🎯 Changes

useQuery/queryOptions's whole-options getter overload (useQuery(() => ({...})) / queryOptions(() => ({...}))) failed to type-check the queryFn: cond ? fn : skipToken pattern shown in their own JSDoc examples.

Root cause: SkipToken is a unique symbol. When a function has more than one overload and the argument is a getter, TypeScript fails to propagate the contextual type into a ternary inside the getter's body, widening the ternary's unique symbol branch to plain symbol — which no longer matches any overload. This repo already has a fix for the same issue in useQueries.ts (SkipTokenForUseQueries = symbol).

The same widening needs to apply consistently everywhere queryFn is accepted as input, but useQuery.ts and queryOptions.ts each hand-wrote their own, independently-drifting mapped type for the options they accept, so queryOptions() didn't accept a computed queryFn at all (only useQuery's options type did), and a bare reactive getter for the whole queryKey array was accepted by queryOptions() but rejected by useQuery()/useQueries() for no principled reason (confirmed at runtime — cloneDeepUnref already resolves a bare-getter queryKey).

This PR:

• Moves UseQueryOptions (previously defined ad hoc in useQuery.ts) into queryOptions.ts. QueryOptions stays the plain/output type — enabled/queryKey reactive, everything else (including queryFn) plain with unique symbol — so queryOptions()'s return value still satisfies QueryClient methods like fetchQuery/invalidateQueries that expect unique symbol, and so useQueries' type-level inference (which pattern-matches on a plain queryFn union) keeps working when a queryOptions() result is spread into it.
• UseQueryOptions (the shared input type for useQuery, useQueries, useBaseQuery, and queryClient) sources its enabled/queryKey/queryFn mappings from QueryOptions, so the two can't drift apart again, and widens SkipToken to symbol only on queryFn there, so queryFn: cond ? fn : skipToken type-checks both inside a whole-options getter and as a computed.
• queryOptions() keeps a narrower input than useQuery(): enabled/queryKey/queryFn accept a ref/computed/getter, every other option stays a plain value (e.g. staleTime: ref(...) is still rejected, and so is wrapping the whole options object in a ref) — the same shape queryOptions() already had, with queryFn added. Both rejections are pinned with @ts-expect-error regression tests.
• Allows a bare reactive getter for the whole queryKey array on useQuery/useQueries (previously @ts-expect-error'd), matching what queryOptions() already accepted and what the runtime already resolves.
• Adds runtime tests (useQuery.test.ts, useQueries.test.ts, useInfiniteQuery.test.ts) confirming a computed queryFn that flips to skipToken actually skips the query and re-runs once defined — not just a type-only check.
• useInfiniteQuery/infiniteQueryOptions were checked for the same issue and found already correct (their options type wraps every property, including queryFn, in MaybeRefDeep as a whole); added regression tests (infiniteQueryOptions.test-d.ts, a runtime test in useInfiniteQuery.test.ts) rather than changing their types.

No other runtime behavior changes.

✅ Checklist

• I have followed the steps in the Contributing guide.
• I have tested code changes locally with pnpm run test:pr, or these tests do not apply to this pull request.
• I fully understand the code in this pull request, including any code generated with AI assistance.

🚀 Release Impact

• This change affects published code, and I have generated a changeset.
• This change is docs/CI/dev-only (no release).